A shared cluster database system is mainly used for an on-line transaction processing (OLTP) application. The application needs to support a large number of concurrent users to periodically add and modify data. Therefore, the entire database system needs to manage a large number of locks of all types. Common locks include a page lock, a routine lock, a tuple lock, and the like. Because the database system needs to use the locks to ensure consistency of various states of a database, lock acquiring and lock releasing, like an input/output (I/O) operation, is generally one of most time-consuming operations in the database system. Therefore, a design of a lock subsystem in the database affects performance of the entire database system to a great extent.
In addition to managing all types of locks, the lock subsystem further needs to implement a lock acquiring or lock releasing operation for these locks. A locking state of each lock includes two locking states: Shared lock held and Exclusive lock held. Therefore, the lock acquiring or lock releasing operation may include an operation of acquiring a shared lock or an operation of releasing a shared lock and an operation of acquiring an exclusive lock or an operation of releasing an exclusive lock.
At present, a lock acquiring or lock releasing operation of a lock is mainly implemented in the following manner:
A processing node (PN) sends a request message to a central coordinator node (CN). The request message includes information about a target lock. The request message may be a lock acquiring request message or a lock releasing request message. If the request message is the lock acquiring request message, the request message includes a request message for requesting to acquire a shared lock or a request message for requesting to acquire an exclusive lock.
After receiving the request message, the CN searches for the target lock according to the information about the target lock. If the request message is the lock acquiring request message, and a lock can be acquired for the target lock, lock acquiring is performed on the target lock, and a message indicating that lock acquiring is successful is returned to the PN. If the request message is the lock acquiring request message, and no lock can be acquired for the target lock at present, a request message for requesting the PN to join a waiting queue of the target lock is sent to the PN. If the request message is the lock releasing request message, lock releasing is performed on the target lock. If the waiting queue of the target lock includes other PNs, one PN is selected from the other PNs, and a notification message is sent to the PN to implement transfer of the target lock.
In the foregoing technology, a PN must perform message exchange with a CN to complete a lock acquiring or lock releasing operation of any lock. However, in an actual application, the number of lock acquiring or lock releasing operations that a PN performs on a lock is huge. In this way, a CN needs to process a great number of lock messages, which causes the CN to easily reach a performance bottleneck, thereby causing low performance of a database system.